Date: Wed, 10 Aug 94 04:30:02 PDT 

From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu> 
Errors-To: TCP-Group-Errors@UCSD.Edu 

Reply-To: TCP-Group@UCSD.Edu 

Precedence: Bulk 

Subject: TCP-Group Digest V94 #169 

To: tcp-group-digest 


TCP-Group Digest Wed, 10 Aug 94 Volume 94 : Issue 169 


Today's Topics: 
PK-88 for TCP/IP in KISS mode (3 msgs) 
TCP-Group Digest V94 #168 
uploaded wnos4a11.tgz 


Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>. 
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>. 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the TCP-Group Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Tue, 9 Aug 1994 7:43:34 -0700 (PDT) 
From: Greg Merrell <GREG@mail.msm.com> 
Subject: PK-88 for TCP/IP in KISS mode 
To: GOLDEN@val5.ed.ray.com 


Dave Golden N1IMS (golden@val5.ed.ray.com) asked: 


Are there any known problems using a PK-88 with GRINOS (or any other 
NOS variant)? I seem to have a good signal into the local switches, 
but invariably I have problems making connections, etc after a few 
minutes. I used to blame it on hidden transmitters, etc. but I'm 
wondering if there may be other forces at work. AX25 connections appear 
to work normally even while the IP stuff goes to heck. 


VVVV VV 


I've found that many connectivity/reliability problems can be fixed by 
properly setting the deviation level of the transmitter. Most of the TNC's 
I've seen have the level set way too hot and the end result is distortion at 
the receive end. There are two reasonable ways that I use to set the level: 


1) Borrow a deviation meter and set the level to between 3 and 3.5 KHz (this 


is the best way!) or 


2) Get another radio so you can listen to your packet station. Set the tx 
deviation level to max and hear what it sounds like. For many radios, this is 
around 6-7 KHz deviation. Then back it off until it sounds only about half as 
loud. Even thought it is very subjective, it is usually close enough and is at 
least low enough to prevent the distortion. 


When I first got involved in packet my station was really ‘hot' and my connect 
rate was very sporadic. Once I set the level down, it connected right up and 
I've had no problems since. 


Greg 


Greg Merrell Internet: greg@msm.com 
MSM Company Internet Services Packet Radio: kc6tyj @ nOary.#nocal.ca.usa.na 
Cupertino, CA 


Date: Tue, 9 Aug 94 21:00:26 EDT 

From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW) 
Subject: PK-88 for TCP/IP in KISS mode 

To: tcp-group@ucsd.edu 


Are there any known problems using a PK-88 with GRINOS (or any other 
NOS variant)? I seem to have a good signal into the local switches, 
but invariably I have problems making connections, etc after a few 
minutes. I used to blame it on hidden transmitters, etc. but I'm 
wondering if there may be other forces at work. AX25 connections appear 
to work normally even while the IP stuff goes to heck. 


VV VV VV 


We had a switch site that had a PK-88 on it (was a NOS system switch) 

and the tnc would lock up a lot or just plain quit working. It always 
worked in cmd: mode though. A local TCP/IP'er here had a PK-88 and he 
ran into the exact same problems. Plus there was a chirp on the transmit 
that could not be fixed (without maybe a component change) when it was 

in KISS mode. Plus it went deaf a lot. He finally replaced it with a 
Kantronics tnc. The PK-88 works just great though in cmd: mode. Also 

a local FBB put a PK-88 online in KISS mode with BPQ. The exact same 
problems as the other 2 systems occured. WOrked great in cmd: mode though. 


I believe that there is something wrong with PK-88's and KISS mode, but 
some people have no problems. The tnc's I described were bought over a 
few years, so I doubt serial numbers of software versions were close. 
PK-232's and PK-900's work fine though in KISS mode. 


Ron N8FOW 


Date: Tue, 9 Aug 1994 23:44:27 -0500 (CDT) 

From: Gerald J Creager <gerry@cs.tamu.edu> 
Subject: PK-88 for TCP/IP in KISS mode 

To: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW) 


Just a thought... I seem to recall finding that long packets (> 1000 bytes) 
died on the pk-88. I could be wrong, tho'. It just might be > 1k. We were 
trying to operate on a "safe" channel in a lan configuration, and had cranked 
the parameters up to ethernet standards... 


73, gerry n5jxs 
gerry@cs.tamu.edu 


Date: Tue, 09 Aug 94 18:58:29 GMT-1 
From: Postmaster@86wg.ram.af.mil 
Subject: TCP-Group Digest V94 #168 
To: tcp-group@UCSD.EDU 


Returned Mail: User cgscmpa@86wg.ram.af.mil Unknown 


xxx Returned Mail Message Follows: xxx 
>From @ramstein.af.mil:owner-tcp-digest@UCSD.EDU Tue 09 Aug 1994 18:56 
X-Envelope-To: cgscmpa@86wg.ra 
id AA28943; Tue, 9 Aug 94 17:49:14 GMT 
Received: by ucsd.edu; id EAA24348 
sendmail 8.6.9/UCSD-2.2-sun 
Tue, 9 Aug 1994 04:30:08 -0700 for tcp-digest-list 
Received: by ucsd.edu; id EAA24318 
sendmail 8.6.9/UCSD-2.2-sun 
Tue, 9 Aug 1994 04:30:06 -0700 for tcp-group-ddist 
Message-Id: <199408091130.EAA24318@ucsd.edu> 
Date: Tue, 9 Aug 94 04:30:02 PDT 
From: Advanced Amateur Radio Networking Group <tcp-group@UCSD.EDU> 
Errors-To: TCP-Group-Errors@UCSD.EDU 
Reply-To: TCP-Group@UCSD.EDU 
Precedence: Bulk 
Subject: TCP-Group Digest V94 #168 
To: tcp-group-digest@UCSD.EDU 


TCP-Group Digest Tue, 9 Aug 94 Volume 94 : Issue 168 


Today's Topics: 
DNS (4 msgs) 
NET/ROM, TexNet and Rose Information 
SMTP LZW oddity 
TCP-Group Digest V94 #167 (2 msgs) 


Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>. 
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>. 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the TCP-Group Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Mon, 08 Aug 94 16:23:00 -0000 

From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) 
Subject: DNS 

To: TCP-Group@UCSD.EDU 


RF> I need to configure ka9q as a DNS. The version that I have does not 
RF> appear to support DNS. Therefore which copy of ka9q or other variety of 
RF> nos do I require to produce a DNS 


My advice is: don't do it. If you need a good, reliable name server, use 
Linux. None of the NOS DNS code I have seen correctly implements the most 
basic elements of the standards, such as TTL and authoritativeness, and is 
really only useful in slave mode. The Linux named seems to be very solid, and 
has all of the same bells and whistles as BSD Unix. 


If you need to put it on the radio, then you could try the kernel patches for 
AX.25 or even link the Linux box to a KA9Q machine with Ethernet. 


-- Mike 


P.S. We found a bug in the 1.1.39 Linux beta kernel that affects DNS. If you 
are a primary authoritative server from which secondary authoritative servers 
attempt to do zone refresh, the zone refresh fails. We don't know why, but the 
current release kernel, 1.0.9, works fine. 


Date: Mon, 08 Aug 1994 17:33:09 -0400 


From: "Brandon S. Allbery" <bsa@kf£8nh.wariat.org> 
Subject: DNS 
To: mikebw@bilow.bilow.uu.ids.net 


In your message of Mon, 08 Aug 1994 16:23:00 -0000, you write: 


| My advice is: don't do it. I£ you need a good, reliable name server, use 
| Linux. None of the NOS DNS code I have seen correctly implements the most 
| basic elements of the standards, such as TTL and authoritativeness, and is 
| really only useful in slave mode. The Linux named seems to be very solid, 
and 

| has all of the same bells and whistles as BSD Unix. 


That's because it *isx the BSD named... Linux kernel networking code isn't 
based on BSD kernel networking code, but most of the non-kernel network code 
is straight BSD. 


| If you need to put it on the radio, then you could try the kernel patches for 
| AX.25 or even link the Linux box to a KA9Q machine with Ethernet. 


Or JNOS/Linux via SLIP over a pty (works fine here!). 


++Brandon 
Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org 
Linux development: iBCS2, JNOS, MH 


Date: Mon, 08 Aug 1994 17:33:09 -0400 

From: "Brandon S. Allbery" <bsa@kf£8nh.wariat.org> 
Subject: DNS 

To: mikebw@bilow.bilow.uu.ids.net 


In your message of Mon, 08 Aug 1994 16:23:00 -0000, you write: 


| My advice is: don't do it. If you need a good, reliable name server, use 
| Linux. None of the NOS DNS code I have seen correctly implements the most 
| basic elements of the standards, such as TTL and authoritativeness, and is 
| really only useful in slave mode. The Linux named seems to be very solid, 
and 

| has all of the same bells and whistles as BSD Unix. 


That's because it *is* the BSD named... Linux kernel networking code isn't 
based on BSD kernel networking code, but most of the non-kernel network code 


is straight BSD. 


| If you need to put it on the radio, then you could try the kernel patches for 
| AX.25 or even link the Linux box to a KA9Q machine with Ethernet. 


Or JNOS/Linux via SLIP over a pty (works fine here!). 


++Brandon 


Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org 
Linux development: iBCS2, JNOS, MH 


Date: Mon, 8 Aug 1994 23:24:12 -0500 (CDT) 
From: ssampson@sabea-oc.af£f.mil (Steve Sampson) 
Subject: DNS 

To: tcp-group@ucsd.edu 


> Which version of NOS has DNS? 


The versions in ftp.ucsd.edu: /hamradio/packet/tcpip 


/ka9q (NOS) 
/paOgri (GRINOS) 
/wg7j (JNOS) 


My favorite is NetBSD, GRINOS, JNOS, NOS, in that order :-) 
But I just got my copy of Yggdrasil Linux, so we'll 
see how it's DNS (named) fairs... 


Steve, N50WK 


Date: Mon, 8 Aug 94 11:42 CST 

From: emillar@enlaces.ufro.cl (Eduardo Millar) 
Subject: NET/ROM, TexNet and Rose Information 
To: ham-digital@ucsd.edu 


Hello: Does anyone could give me information about NET/ROM, TexNet and Rose? 


Eduardo Millar C. e-mail: emillar@enlaces.ufro.cl 
Proyecto Enlaces fono/fax: 250759 


Universidad de la frontera Casilla 380 Temuco - Chile 


Date: Mon, 08 Aug 94 16:33:00 -0000 

From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) 
Subject: SMTP LZW oddity 

To: TCP-Group@UCSD.EDU 


A> In all the code I've seen (apart from my own modified versions), 
A> the SMTP LZW exchange goes like this: 


A> Client sends "XLZW <x> <y>" 


A> Server checks that it can do LZW with these parameters, if so it 
A> replies with "25n XLZW <m> <n> OK" and goes to compressed mode. 


A> The client checks the response, and iff (m = x) and (n = y) then 
A> it too goes to compressed mode. 


It is not true that (m = x) and (n = y) are the requirements. In fact, the 
requirement is only that (m <= x) and (n <= y), as I recall. 


A> My question is: why does the client check <m> and <n> ? It's too 
A> late for the client to decide to not go to compressed mode - the 
A> server has already gone compressed. 


The client offers to do compression and says, "I have enough memory and 
processing resources to use a maximum of (x, y) compression. How are you 
feeling today?" The server may then answer, "I have only enough resources to 
do (m, n) compression, where (m < x) or (n < y)." 


A> The server code looks as though, in theory, it could return different 
A> values from those the client supplied. 


As long as the protocol requires that the server return a maximum of the offer 
made by client, there is no problem. After all, the server cannot use higher 


compression than the client is capable of supporting. 


A> There may not necessarily be a problem in practice, but froma 
A> protocol point of view the exchange seems wrong. 


It probably could have been done better. 


-- Mike 


Date: Tue, 9 Aug 1994 09:51:28 CET 

From: "Jack Stiekema" <JACK@vic1.victron.nl> 
Subject: TCP-Group Digest V94 #167 

To: freemanr@dstos3.dsto.gov.au, tcp-group@ucsd.edu 


>>Date: Sun, 7 Aug 1994 23:42:15 -0700 

>>From: freemanr@dstos3.dsto.gov.au (Roy Freeman) 

>>To: TCP-Group@UCSD.EDU 

>> 

>>I need to configure ka9q as a DNS. The version that I have does not appear 
>>to support DNS. Therefore which copy of ka9q or other variety of 

>>nos do I require to produce a DNS 


The originals are at ftp.ucsd.edu somewhere in 
pub/ham/packet/tcpip/ka9q. 
There is also a working exe with DNS. 


Cheers, 


Kind regards, 
Jack Stiekema 
Product Manager Connectivity 


| Phone: +31 50 446284 or +31 6 53145069 | 
| Fax: +31 50 424107 Email jack@victron.nl | 
| Victron by POB 31 9700 AA Groningen Holland | 


Date: Tue, 09 Aug 94 12:57:25 GMT-1 
From: Postmaster@86wg.ram.af.mil 
Subject: TCP-Group Digest V94 #167 
To: tcp-group@UCSD.EDU 


Returned Mail: User cgscmpa@86wg.ram.af.mil Unknown 


xxx Returned Mail Message Follows: xxx 
>From @ramstein.af.mil:owner-tcp-digest@UCSD.EDU Tue 09 Aug 1994 12:55 
X-Envelope-To: cgscmpa@86wg.ra 
id AA11829; Mon, 8 Aug 94 18:16:22 GMT 
Received: by ucsd.edu; id EAA02739 
sendmail 8.6.9/UCSD-2.2-sun 
Mon, 8 Aug 1994 04:30:06 -0700 for tcp-digest-list 
Received: by ucsd.edu; id EAA02730 
sendmail 8.6.9/UCSD-2.2-sun 


Mon, 8 Aug 1994 04:30:05 -0700 for tcp-group-ddist 
Message-Id: <199408081130.EAAQ2730@ucsd.edu> 
Date: Mon, 8 Aug 94 04:30:03 PDT 
From: Advanced Amateur Radio Networking Group <tcp-group@UCSD.EDU> 
Errors-To: TCP-Group-Errors@UCSD.EDU 
Reply-To: TCP-Group@UCSD.EDU 
Precedence: Bulk 
Subject: TCP-Group Digest V94 #167 
To: tcp-group-digest@UCSD.EDU 


TCP-Group Digest Mon, 8 Aug 94 Volume 94 : Issue 167 


Today's Topics: 
SMTP LZW oddity 


Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>. 
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>. 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the TCP-Group Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Mon, 8 Aug 94 09:46:48 +0100 

From: A.D.S.Benham@bnr.co.uk 

Subject: SMTP LZW oddity 

To: TCP-Group@UCSD.Edu, nos-bbs@hydra.carleton.ca 


In all the code I've seen (apart from my own modified versions), 
the SMTP LZW exchange goes like this: 


Client sends "XLZW <x> <y>" 


Server checks that it can do LZW with these parameters, if so it 
replies with "25n XLZW <m> <n> OK" and goes to compressed mode. 


The client checks the response, and iff (m = x) and (n = y) then 


it too goes to compressed mode. 


My question is: why does the client check <m> and <n> ? It's too 
late for the client to decide to not go to compressed mode - the 


server has already gone compressed. 


The server code looks as though, in theory, it could return different 
values from those the client supplied. 

There may not necessarily be a problem in practice, but from a 
protocol point of view the exchange seems wrong. 


Andrew Benham 


adsb@bnr.co.uk BNR Europe Ltd, 140 Greenway, Harlow Business Park, 
Harlow, Essex CM19 5QD 
+44 279 402372 Fax: +44 279 402029 
Home: e8fsl@g8fsl.ampr.org [44.131.181.17] 


Date: Sun, 7 Aug 1994 23:42:15 -0700 
From: freemanr@dstos3.dsto.gov.au (Roy Freeman) 
To: TCP-Group@UCSD.EDU 


I need to configure ka9q as a DNS. The version that I have does not appear 
to support DNS. Therefore which copy of ka9q or other variety of 
nos do I require to produce a DNS 


End of TCP-Group Digest V94 #167 
KKKKKKKKKKKKKKKKKKKKKKKEKRKEKR KAKA A 


Date: Mon, 08 Aug 1994 20:39:11 -0400 
From: "Scot M. Gardner" <smg@math.ufl.edu> 
To: tcp-group@UCSD.EDU 


+- On Monday (8/8/1994 18:11) "Scot M. Gardner" <smg@math.ufl.edu> Wrote- 


Ack! My appologies. That was supposed to be to tcp-group-request, 
NOT to tcp-group. 


A previous sysadmin subscribed root and now I'm trying 
to get off! Of course, I don't know what they subscribed 


under. 


Can list admin remove me, please??! 


Once again, my apologies. 


| list root@math.ufl.edu 
| list root@matrix.math.ufl.edu 
| list root@mathlab.math.ufl.edu 
| list netadm@matrix.math.ufl.edu 
| list system@matrix.math.ufl.edu 
| list system@mathlab.math.ufl.edu 
Scot Gardner 
University of Florida Department of Mathematics 
Computer Programmer/Analyst (904) 392-8501, Walker 3 
Scot M. Gardner email: smg@math.ufl.edu 
web:<a href="http://www.math.ufl.edu/~smg">click</a> 


Date: Mon, 8 Aug 1994 18:11:11 -0400 
From: "Scot M. Gardner" <smg@math.uf1l.edu> 
To: tcp-group@ucsd.edu 


list root@math.ufl.edu 

list root@matrix.math.ufl.edu 
list root@mathlab.math.ufl.edu 
list netadm@matrix.math.ufl.edu 
list system@matrix.math.ufl.edu 
list system@mathlab.math.ufl.edu 


End of TCP-Group Digest V94 #168 
KKKKK KKK KKK IIIA AKA KAKA AKER ERK 


Date: Wed, 10 Aug 94 08:58:07 EST 

From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm. gmd.de> 
Subject: uploaded wnos4a11.tgz 

To: TCP-GROUP <TCP-GROUP@ucsd.edu> 


Hi just another version of wnos src code. 
please feel free to do what ever you wish with it. 
test it hack it about even discard it. 


this version is much hacked about in netrom nntp and ftp cli/serv 
the memory leak is gone as far as i can see. I have compiled it ONLY 
with BC++ 2.00 as BC++ 3.x seems to bring out the worst case of mem leak 


i have seen. so please dont use BC++ 3.x only use version 2.00 


as always no garantes use at your risk, 


im working on dama_slave to this code. and will likely get some time to 
finish that soon. (3-5 weeks) 

wnos-5 is not completely dead, im makeing a hacked version that 

works time permitting. and with co-coperation of others hb9zz dg1zx 
dl6zba and any others that might feel free to hack at the code. 

wnos-5 src and docs are in ftp.ucsd.edu 

as is wnos4a11.tgz = tar.gz cos ido it on my linux box. 

there are dos utils called tar.exe and gzip.exe about to unpack the 
file if you done have a unix box to hand. 

habe fun Barry dcOhk/gm8sau 


End of TCP-Group Digest V94 #169 
KAKKKKKKKKKKKKKKKKKKKEKKEKRKE KAKA 


